Java JVM学习-常见问题
说一下 JVM 的主要组成部分？及其作用？
- 类加载器（ClassLoader）
- 运行时数据区（Runtime Data Area）
- 执行引擎（Execution Engine）
- 本地库接口（Native Interface）
各组件的作用：首先通过类加载器（ClassLoader）会把 Java 代码转换成字节码，运行时数据区（Runtime Data Area）再把字节码加载到内存中，而字节码文件只是 JVM 的一套指令集规范，并不能直接交给底层操作系统去执行，因此需要特定的命令解析器执行引擎（Execution Engine），将字节码翻译成底层系统指令，再交由 CPU 去执行，而这个过程中需要调用其他语言的本地库接口（Native Interface）来实现整个程序的功能。
谈谈对运行时数据区的理解？
由 堆、栈、程序计数器、本地方法栈、方法区 五部分组成。
堆中存什么？栈中存什么？
堆中存的是对象。栈中存的是基本数据类型和堆中对象的引用。一个对象的大小是不可估计的，或者说是可以动态变化的，但是在栈中，一个对象只对应了一个 4byte 的引用（堆栈分离的好处）。
为什么不把基本类型放堆中呢？
因为基本数据类型占用的空间一般是1~8个字节，需要空间比较少，而且因为是基本类型，所以不会出现动态增长的情况，长度固定，因此栈中存储就够了。
如果把它存在堆中是没有什么意义的。基本类型和对象的引用都是存放在栈中，而且都是几个字节的一个数，因此在程序运行时，它们的处理方式是统一的。但是基本类型、对象引用和对象本身就有所区别了，因为一个是栈中的数据一个是堆中的数据。最常见的一个问题就是，Java 中参数传递时的问题。
为什么要把堆和栈区分出来呢？栈中不是也可以存储数据吗？
1、栈因为运行时的需要，比如：保存系统运行的上下文，需要进行地址段的划分。由于栈只能向上增长，因此就会限制住栈存储内容的能力。 而堆不同，堆中的对象是可以根据需要动态增长的，因此栈和堆的拆分，使得动态增长成为可能，相应栈中只需记录堆中的一个地址即可。
2、堆与栈的分离，使得堆中的内容可以被多个栈共享（也可以理解为多个线程访问同一个对象）。这种共享的收益是很多的。一方面这种共享提供了一种有效的数据交互方式（如：共享内存），另一方面，堆中的共享常量和缓存可以被所有栈访问，节省了空间。
3、从软件设计的角度看，栈代表了处理逻辑，而堆代表了数据。这样分开，使得处理逻辑更为清晰。分而治之的思想。这种隔离、模块化的思想在软件设计的方方面面都有体现。
判断垃圾可以回收的方法有哪些？
垃圾收集器在对堆区和方法区进行回收前，首先要确定这些区域的对象哪些可以被回收，哪些暂时还不能回收，这就要用到判断对象是否存活的算法。
- 引用计数法
- 可达性分析算法
被标记为垃圾的对象一定会被回收吗？
即使在可达性分析算法中不可达的对象，也并非是 “非死不可”，这时候它们暂时处于 “缓刑” 阶段，要真正宣告一个对象死亡，至少要经历两次标记过程。
第一次标记：如果对象在进行可达性分析后发现没有与 GC Roots 相连接的引用链，那它将会被第一次标记；
第二次标记：第一次标记后接着会进行一次筛选，筛选的条件是此对象是否有必要执行 finalize() 方法。在 finalize() 方法中没有重新与引用链建立关联关系的，将被进行第二次标记。第二次标记成功的对象将真的会被回收，如果对象在 finalize() 方法中重新与引用链建立了关联关系，那么将会逃离本次回收，继续存活。
垃圾回收是从哪里开始的呢？
查找哪些对象是正在被当前系统使用的。上面分析的堆和栈的区别，其中栈是真正进行程序执行地方，所以要获取哪些对象正在被使用，则需要从 Java 栈开始。同时，一个栈是与一个线程对应的，因此，如果有多个线程的话，则必须对这些线程对应的所有的栈进行检查。
同时，除了栈外，还有系统运行时的寄存器等，也是存储程序运行数据的。
这样，以栈或寄存器中的引用为起点，我们可以找到堆中的对象，又从这些对象找到对堆中其他对象的引用，这种引用逐步扩展，最终以 null 引用或者基本类型结束，这样就形成了一颗以 Java 栈中引用所对应的对象为根节点的一颗对象树。
如果栈中有多个引用，则最终会形成多颗对象树。在这些对象树上的对象，都是当前系统运行所需要的对象，不能被垃圾回收。而其他剩余对象，则可以视为无法被引用到的对象，可以被当做垃圾进行回收。
谈谈对 Java 中引用的了解？
- 强引用：不回收
- 软引用：内存不足即回收
- 弱引用：发现即回收
- 虚引用：对象回收跟踪
谈谈对内存泄漏的理解？
在 Java 中，内存泄漏就是存在一些不会再被使用确没有被回收的对象，这些对象有下面两个特点：
- 这些对象是可达的，即在有向图中，存在通路可以与其相连；
- 这些对象是无用的，即程序以后不会再使用这些对象。
如果对象满足这两个条件，这些对象就可以判定为 Java 中的内存泄漏，这些对象不会被 GC 所回收，然而它却占用内存。
内存泄露的根本原因是什么？
长生命周期的对象持有短生命周期对象的引用就很可能发生内存泄漏，尽管短生命周期对象已经不再需要，但是因为长生命周期持有它的引用而导致不能被回收，这就是 Java 中内存泄漏的发生场景。
尽量避免内存泄漏的方法？
- 尽量不要使用 static 成员变量，减少生命周期；
- 及时关闭资源；
- 不用的对象，可以手动设置为 null。
常用的垃圾收集算法有哪些？
标记-清除算法（Mark-Sweep）
标记-清除算法采用从根集合（GC Roots）进行扫描，对存活的对象进行标记，标记完毕后，再扫描整个空间中未被标记的对象，进行回收。标记-清除算法不需要进行对象的移动，只需对不存活的对象进行处理，在存活对象比较多的情况下极为高效，但由于标记-清除算法直接回收不存活的对象，因此会造成内存碎片。
复制算法（Copying）
复制算法的提出是为了克服句柄的开销和解决内存碎片的问题。它开始时把堆分成 一个对象面和多个空闲面， 程序从对象面为对象分配空间，当对象满了，基于 copying 算法的垃圾收集就从根集合（GC Roots）中扫描活动对象，并将每个活动对象复制到空闲面（使得活动对象所占的内存之间没有空闲洞），这样空闲面变成了对象面，原来的对象面变成了空闲面，程序会在新的对象面中分配内存。
标记-整理算法（Mark-compact）
标记-整理算法采用标记-清除算法一样的方式进行对象的标记，但在清除时不同，在回收不存活的对象占用的空间后，会将所有的存活对象往左端空闲空间移动，并更新对应的指针。标记-整理算法是在标记-清除算法的基础上，又进行了对象的移动，因此成本更高，但是却解决了内存碎片的问题。
分代收集算法
分代收集算法是目前大部分 JVM 的垃圾收集器采用的算法。它的核心思想是根据对象存活的生命周期将内存划分为若干个不同的区域。一般情况下将堆区划分为老年代（Tenured Generation）和新生代（Young Generation），在堆区之外还有一个代就是永久代（Permanet Generation）。
老年代的特点是每次垃圾收集时只有少量对象需要被回收，而新生代的特点是每次垃圾回收时都有大量的对象需要被回收，那么就可以根据不同代的特点采取最适合的收集算法。例如老年代可以使用标记-整理算法，而垃圾较多的新生代可以使用复制算法
为什么要采用分代收集算法？
不同的对象的生命周期是不一样的。因此，不同生命周期的对象可以采取不同的收集方式，以便提高回收效率。（具体看上面）
常用的垃圾收集器有哪些？
Serial 收集器（复制算法）
新生代单线程收集器，标记和清理都是单线程，优点是简单高效。是 client 级别默认的 GC 方式，可以通过 -XX:+UseSerialGC 来强制指定。
Serial Old 收集器（标记-整理算法）
老年代单线程收集器，Serial 收集器的老年代版本。
ParNew 收集器（停止-复制算法）
新生代收集器，可以认为是 Serial 收集器的多线程版本，在多核 CPU 环境下有着比 Serial 更好的表现。
Parallel Scavenge 收集器（停止-复制算法）
并行收集器，追求高吞吐量，高效利用 CPU。
吞吐量一般为 99%， 吞吐量 = 用户线程时间 / (用户线程时间+GC线程时间)。适合后台应用等对交互相应要求不高的场景。是 server 级别默认采用的GC方式，可用 -XX:+UseParallelGC 来强制指定，用 -XX:ParallelGCThreads=4 来指定线程数。
Parallel Old 收集器（停止-复制算法）
Parallel Old 收集器的老年代版本，并行收集器，吞吐量优先。
CMS（Concurrent Mark Sweep）收集器（标记-清除算法）
高并发、低停顿，追求最短 GC 回收停顿时间，cpu 占用比较高，响应时间快，停顿时间短，多核 cpu 追求高响应时间的选择。 CMS 是英文 Concurrent Mark-Sweep 的简称，是以牺牲吞吐量为代价来获得最短回收停顿时间的垃圾回收器。对于要求服务器响应速度的应用上，这种垃圾回收器非常适合。在启动 JVM 的参数加上“-XX:+UseConcMarkSweepGC”来指定使用 CMS 垃圾回收器。 CMS 使用的是标记-清除的算法实现的，所以在 GC 的时候会产生大量的内存碎片，当剩余内存不能满足程序运行要求时，系统将会出现 Concurrent Mode Failure，临时 CMS 会采用 Serial Old 回收器进行垃圾清除，此时的性能将会被降低。
垃圾回收时机？
Minor / Scavenge GC
所有对象创建在新生代的 Eden 区，当 Eden 区满后触发新生代的 Minor GC，将 Eden 区和非空闲 Survivor 区存活的对象复制到另外一个空闲的 Survivor 区中。保证一个 Survivor 区是空的，新生代 Minor GC 就是在两个 Survivor 区之间相互复制存活对象，直到 Survivor 区满为止。
Minor/Scavenge 这种方式的 GC 是在年轻代的 Eden 区进行，不会影响到年老代。因为大部分对象都是从 Eden 区开始的，同时 Eden 区不会分配的很大，所以 Eden 区的 GC 会频繁进行。因而，一般在这里需要使用速度快、效率高的算法，使 Eden 去能尽快空闲出来。
Major GC
发生在老年代的GC ，基本上发生了一次Major GC 就会发生一次 Minor GC。并且Major GC 的速度往往会比 Minor GC 慢 10 倍。 什么时候会发生 Major GC 呢？
- 对于一个大对象，我们会首先在Eden 尝试创建，如果创建不了，就会触发Minor GC
- 随后继续尝试在Eden区存放，发现仍然放不下
- 尝试直接进入老年代，老年代也放不下
- 触发 Major GC 清理老年代的空间
Full GC
对整个堆进行整理，包括 Young、Tenured 和 Perm。Full GC 因为需要对整个堆进行回收，所以比 Minor GC 要慢，因此应该尽可能减少 Full GC 的次数。在对 JVM 调优的过程中，很大一部分工作就是对于 Full GC 的调节。
说下你用过的 JVM 监控工具？
- jvisualvm：虚拟机监视和故障处理平台
- jps ：查看当前 Java 进程
- jstat：显示虚拟机运行数据
- jmap：内存监控
- jhat：分析 heapdump 文件
- jstack：线程快照
- jinfo：虚拟机配置信息
如何利用监控工具调优？
1、堆信息查看
- 可查看堆空间大小分配（年轻代、年老代、持久代分配）
- 提供即时的垃圾回收功能
- 垃圾监控（长时间监控回收情况）
- 查看堆内类、对象信息查看：数量、类型等
- 对象引用情况查看
有了堆信息查看方面的功能，我们一般可以顺利解决以下问题：
- 年老代年轻代大小划分是否合理
- 内存泄漏
- 垃圾回收算法设置是否合理
2、线程监控
线程信息监控：系统线程数量 线程状态监控：各个线程都处在什么样的状态下 Dump 线程详细信息：查看线程内部运行情况 死锁检查
3、热点分析
CPU 热点：检查系统哪些方法占用的大量 CPU 时间；
内存热点：检查哪些对象在系统中数量最大（一定时间内存活对象和销毁对象一起统计）这两个东西对于系统优化很有帮助。我们可以根据找到的热点，有针对性的进行系统的瓶颈查找和进行系统优化，而不是漫无目的的进行所有代码的优化。
4、快照
快照是系统运行到某一时刻的一个定格。在我们进行调优的时候，不可能用眼睛去跟踪所有系统变化，依赖快照功能，我们就可以进行系统两个不同运行时刻，对象（或类、线程等）的不同，以便快速找到问题。
举例说，我要检查系统进行垃圾回收以后，是否还有该收回的对象被遗漏下来的了。那么，我可以在进行垃圾回收前后，分别进行一次堆情况的快照，然后对比两次快照的对象情况。
5、内存泄露检查
内存泄漏是比较常见的问题，而且解决方法也比较通用，这里可以重点说一下，而线程、热点方面的问题则是具体问题具体分析了。
内存泄漏一般可以理解为系统资源（各方面的资源，堆、栈、线程等）在错误使用的情况下，导致使用完毕的资源无法回收（或没有回收），从而导致新的资源分配请求无法完成，引起系统错误。内存泄漏对系统危害比较大，因为它可以直接导致系统的崩溃。